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ABSTRACT 



The intelligent Maintenance Training System (IMTS) is a set of 
software tools for composing and delivering siimulation-based technical 
training, the goal iii developing IMTS was to generate instructional 
interactions from device models composed of instances of generic objects. 

Prpblem selection in IMTS relies on; the use of a nonnative model that 
i-eflects the structure of the target device. Proficiency measures are 
niiaintained for each student iii terms of this model and support the selection 
of problems of appropriate difficulty and type. 

IMTS incorporates a fonriiUation of genericdiagnpstic expertise, 
termed Profile, that 1) explains die significance of particular test outcomes 
and remediates student beliefs about symptom impUcations, 2) recommends 
what to do next, taking completed tests into account, 3)-assesses student 
proficiency, and 4) debriefs the student following each fault isolation 
exercise. 

A number of findings and recommendations are Lasted. The next steps 
for IMTS development are also outiined, including techniques for 
simulating devices whose complete functional behaviors cannot reasonably 
be specified and the addition of features to support procedural training. 
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SECTION I. INTRODUCTION 



This is the final technical report covering development of the Intelligent 
Maintenance Training System (IMTS) developed at Behavioral Technology 
Laboratories over the past three years. 

The IMTS serves three purposes. First, it is a demonstration of the feasibility 
of-generating device-specific maintenance instruction from generic troubleshooting 
intelligence applied to device specifications. Second, it provides a tool for the 
developinent and delivery of maintenance training for such applications as the SH- 
3H Helicopter Bladefold system and a WSG-3 Satellite Communications System. 
Third, it provides an extendable environment for further research on a variety of 
topics, including the application of direct manipulation methodologies to graphic 
simulation composition; the effectiveness of generated instruction as opposed to 
autiiored instruction; and appropriate roles for interactive graphics in technical 
training. 

The Goal: Maintenance Instruction Derived from Device Models 

An overriding goal in the development of IMTS has been to generate device- 
specific training using device-general intelligence applied to technical specifications 
of a particular device. Of course, hand tailored instructional materials are valuable 
and even necessary in maijy contexts. Still, there are considerable advantages to 
generated instruction. Where instruction can be effectively generated, it may be 
possible to guarantee greater thoroughness, completeness, and consistent accuracy 
than is possible with purely human-generated instructional materials. Generated 
instruction allows meaningful interactions when a huge number of situations and 
requirements could be encountered and allows production of training courseware at 
a reduced cost, in comparison to manually authored instruction. 

Creating instructional interactions at run time based on a device description has 
a number of advantages, botii for the student and for those who must develop, 
mau'tain, and administer the training system. Chief among tiie advantages for tiie 
student is tiiat a wide range of interactions are possible. This makes it feasible for 
students to control many of tiie surface characteristics of theu* interactions with the 
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IMTS tutor/advisor. Students can utilize options of a data-driven system that would 
not be feasible in a system in which all the interactions are pre-authored. For 
example, MIS students can insert simulated malfunctions for which the human 
author has prepared no instructionalmaterials and then experiment with the 
sunulated device exiiibiting that failure mode. 

For the developers and maintainers of a technical training package, there are 
also great advantages to basing training on a device model. Many different kinds of 
aiding and instructional interchanges can be delivered to the student without having 
to be separately authored. If the target device is modified, the corresponding 
change can be made to the description, and all the instructional elements related to 
tiie change will automatically have tiie appropriate form. Similarly, if an error in 
the expert autiior's understanding of tiie device description is detected, it can 
usually be repaired witii a simple change to tiie techrical specification. 

■ Our objective was to make this process as easy as possible. The IMTS 
development system consists of a number of generalized tools for describing 
devices (a "device", as used here, is any collection of component parts). Graphics 
editors are used to draw the components of a device and position tiiem 
appropriately in scenes, a behavior editor is used to describe tiie ways in which 
generic objects function in normal and failed states. Most of tiie actual 
troubleshooting advice and instruction provided to tiie student is created at run time 
by an IMTS generic expert module tiiat has access to tiie device description and to 
tiie student's diagnostic performance. 

Approach 

• 

One key to tiie generation of instruction in tiie IMTS is tiie separation of the 
generic intelligence required to instruct corrective maintenance from tiie device- 
sper'fl". technical information (knowledge) that characterizes each particular 
System. The generic intelligence built into tiie IMTS consists of 1) diagnostic 
expertise, and 2) instructional expertise. 

Because the instructional intelligence is jprovided in tiie IMTS, it is possible for 
technical experts to supply tiie necessary specifications to support training witiiout 

2 
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also requiring instructional expertise, diagnostic expertise, or programming skills. 
The drawback of the approach is that users camiot alter the instructional strategy or 
the diagnostic approach, if they feel that these could be imj-roved or adapted to 
better meet particular requirements. A future version of EMTS may incorporate 
tools for customizing the instructional approach and the diagnostic strategy. 

We now.briefly describe the instructional approach and diagnostic strategy 
employed in the IMTS. 

The Instructional Orientation 

The IMTS was designed to provide troubleshooting practice to technicians 
already trained in general principles (of electronics or hydraulics) and already 
familiar with the appearance, organization, and function of the device they are 
learning to maintain. 

Instruction is simulation-oriented, i.e., the student learns by attempting to 
perform troubleshooting tasks on a sunulation of th^ target device. For each 
ex^^ise, the student is presented with a failure report and a simulation of the 
device, containing a failure selected by the training system. The student performs 
tests and replacements on the simulation until he or she claims that the system has 
been restored to normal operation. When necessary, or upon student request, 
advice and commentary about the student's troubleshooting actions are provided. 

The IMTS training philosophy is built upon a foundation of research in 
intelligent tutoring. Twenty-one principles from tiiis research guided the 
development of instructional decisions within die training context In brief, these 
are the principles, listed with the research studies diat justify them: 

1 . Instruction c»<ould be relevant to the problem-solving context. 
(Tulving, 1983; Tulving & Thompson, 1973) 

2. Provide immediate feedback on errors. 
(Bilodeau, .1969; Skinner, 1958) 
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3. Sustain the simulation session by postponing instructional content which would 
obviate.the inotivation for the session. (Don't give it all away!) 

4. Provide quick response. 

5. Explicitly identify the goal structure of the problem domain. 
(Anderson, Farrell, & Saueirs, 1984) 

6. Minimize the student's working memory load. 
(McKendreei Reiser; & Anderson 1984) 

7. Prevent superstitious behavior. 

8. Help students to approach target skills by successive approximations. 
(Anderson, 1983; Anderson, Farrell,. & Sauers, 1984) 

9. Protect students frona building . extended chains of misconceptions. 

10. Protect students from negative consequences of appropriate actions. 

11. Instruct opportunistically. 

12. Maintain the credibility of the tutor. 

The remaining principles are taken from (Burton & Brown, 1982).' 

13. Before giving advice, be sure that the student needs it. 

14. When illustrating an issue, use an example for which the correct move is 
dramatically superior to the move made by the student. 

15. After remediating, give the student an opportunity to exercise the new 
knowledge. 

16. If the student is about to fail, interrupt and provide moves that will prevent 
faiiure. 

17. Never intervene and tutor on two consecutive student moves. 

18. Don't prevent student discovery by overtutori ig. 

19. Intervene on exceptional successes, as well as on failures. 
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20. Always have the artificial expert: play an optimal game. 

2 1 . R:o vide help in several layers. 

The largely non-invasive, non-controlling nature of the IMTS instructional 
system can be attributed to adherence.to many of these principles. A student who 
has been doing fairly well in a problem will occasionally perform a rather poor 
test. If progress has been generally good in comparison with expert performance, 
the IMTS will remain silent and let the student continue. In this respect, IMTS 
behaviK much like many human tutors, who often allow students to continue when 
their behavior is not optimal, so long as progress is being made. This hands-off 
approach gives students an opportunity to practice without constant interruption. 
Naturally, performance is still monitored in this silent mode, and aid is given to 
help students avoidlpng unproductive periods. Further discussion of these 
principles can be found in an earlier report (Towne, Munro, Pizzini, Surmon, and 
Johnson, 1985). 

Profile — a Generic Model of Diagnostic Expertise 

Under funding from the Engineering Psychology program of the Office of 
Naval Research, BTL developed a generic expert diagnostician called Profile 
(Towne, Fehling, & Bond, 1981; Towne, 1984; 1985; 1986) and conducted 
empirical studies of its troubleshooting behavior in comparison with that of human 
experts (Towne, Johnson, & Corwin, 1982; 1983). The Profile model of diagnostic 
expertise is the foundation for a number of different research efforts at Behavioral 
Technology Laboratories (Figure 1). 

Profile can be applied to generated fault data in several different ways. For 
example, it can be used in conjunction with a commercial computer-aided 
engineering (CAE) package to evaluate designs for their maintainability (Towne & 
Johnson, 1984; 1987). In the research reported on here, Profile is used to generate 
intelligent advice and commentary on troubleshooting actions made on a simulated 
devix. 



A Generic CAD/CAE Syitem 




Figure 1 . Profile Fills Multiple Roles 



Training Configurations 

The present IMTS has been implemented on Xerox Artificial Intelligence 
workstations, including the models 1108, 1186, and 1132. These computers are 
microcoded for Lisp, and they offer high speed graphical displays of moderately 
high resolution (at least 1024 x 800). All MTS development/authoring tools, 
simulation routmes, and instructional presentation routines were written in 
Interlisp-D,, a Lisp dialect for which the Xerox machines have been optimized. 

The IMTS is designed to work in two different training delivery environments, 
either 1) as an intelligent adjunct to some other training device, such as a high- 
fidelity simulator, or 2) as a stand-alone training system. 
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Adjunct Configuration 



When IMTS is connected to an external simulator that adheres to the IMTS 
communications protocol, students can interact primarily with the external 
simulator, relying on the IMTS display for advice and ancillary instruction. The 
high-fidelity simulator involved in this dual-mode configuration might be a full- 
scale inock-up, a coniputer-controlled 2-D simulator, or just a videodisk unit. 

At present, one external simulator, the Generalized Maintenance Trainer 
Simulator (GMTS) supports this communication protocol. GMTS is a 
microcomputer-basedrsurf ace-behavior simiilaitdr that presents color images stored 
on videodisk under computer contrpUTowne, 1986; Munro, Towne, & King, 1980; 
Towne & Munro, 1981; Johnson, Munro, & Towne, 1981). Students use a touch- 
sensitive panel on the external monitor to change controls and to place test 
equipment probes on the displayed video images. 

IMTS supports the textual communication features of GMTS by providing a 
window that acts as a virtual terminal display for the use of the GMTS software 
(Figure 2). This window provides a 25-line by 80-character screen that presents 
the text output of the GMTS computer, replacing the ASCII terminal that is used 
with GMTS simulations not augmented with IMTS instruction. 





Curren; Student : SP:0ENT4 








CUSSROOM ACTIVIHES 








Select a student 








Activate tutorial for current student 
Return to previous menu 






OOW ONE 
« 


UP ONE 
• 


SELECT 
* 


ITEM 


ITEM 


ITEM 



Figure 2. A Virtual Terminal Window Under the Control of GMTS 



The GMTS simulator has no built-in instructional capacities when it is used in 
the.simulated troubleshooting mode (it does provide a general-purpose 
instructional function as a separate facility). Communicating over an RS232 
interface, tiie GMTS informs the IMTS of every action that the student takes. The 
IMTS recognizes what tests are being.performed, and it evaluates them by calling 
Profile. Profile-based evaluations and Profile-generated suggestions provide the 
bulk of the instructional features available in the combined IMTS-GMTS mode. 




Figure 3. Student Interactions in the IMTS/GMTS Environment 

Students can interact with at least three different modules in the integrated 
IMTS/GMTS environment (see Figure 3): 1) they can manipulate and observe the 
functional simulation shown on the IMTS graphics display, 2) they can interact with 
the instruction module in ways that will be described below, or 3) they can 
manipulate and observe the physical surface simulation portrayed by the GMTS 
using videodisk and graphics overlays. 

In fact, the box labeled GMTS in the above figure is not constrained to be a 
videodisk-based simulator. It could as well be a flat panel or a 3-D simulator that 
has a computer interface that can conmaunicate with IMTS using the IMTS/GMTS 
communications protocol. Even an actual device could conceivably be used, so long 
as it was modified so that it would report all user actions to the IMTS using the 



8 

17 



IMTS.communications protocol. Viewed this way, IMTS is an intelligent aiding 
station that can be used with any of a variety of training devices. 

Stand-alone Configuration 

In the stand-alone configuration, cunrentiy under development, the IMTS will 
perform all the simulation and instruction functions without a mediating GMTS 
computer system, as shown in Figure 4. 



IMTS 




Figure 4. Student Interactions, with Stand-alone IMTS 

In this environment, the surface simulation currently provided by GMTS may 
be presented grap'nically on the IMTS computer display or may be displayed using a 
videodisk under the direct control of the IMTS computer. 

IMTS Elements 

Regardless of the configuration (adjunct or stand-alone), the primary elements 
in the IMTS design are these: 

• a functional model of the device, 

• graphical representations of the device, functional and/or physical. 



• a model of the student, 

• generic diagnostic expertise, 

• generic instructional expertise. 

Section n describes techniques for producing and using the functional device 
model, including graphical representations of the device; Section HI describes the 
techniques for modeling the student and selecting appropriate problems; Section IV 
describes the IMTS processes for monitoring student proficiency and progress, and 
for providing appropriate assistance; and Section V presents conclusions. 
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SECTION II. MODELING AND REPRESENTING THE DEVICE 



Virtually all of the IMTS instruction is derived from manipulations of a 
functional model. This model is produced automatically when the functional scenes 
are coniposed, i.e., underlying the graphical representation are all the generic 
object rules and connectivity data necessary to determine the behavior of the 
particular device. Interactions with the student may be based either on the 
functional representation oir upon a physical representation that is created in terms 
of the functional form. We first discuss the functional model and its associated 
representation. 

The Functional Model 

The functional model is regarded as the primary medium for illustrating and 
explaining the behaviors of the target system. The model is represented to the 
student via computer graphic drawings that respond to the effects of the student's 
actions and to inserted failures. The first device we have modeled in this fashion is 
a complex helicopter bladefolding system in which the components are organized as 
thirteen interrelated schematic 'diagrams', or scenes. Figure 5 shows a portion of a 
representative scene from the Bladefold simulation set 

The student changes the setting of a control by selecting the desired new position 
with the mouse (all references to 'selecting' imply that the user positions the mouse 
cursor on the desired object or menu item and clicks the mouse button). The 
simulation is then updated, i.e., all effects of the switch change are determined, 
including effects that are off screen (on other scenes). This complete evaluation is 
necessary, since effects on the currently displayed scene may be caused by changes 
in portions of the simulation not in view (which were in turn caused by the switch 
change accomplished on screen). The currently displayed scene is then updated by 
displaying all new object states, including the switch that was changed. Because the 
non-dynamic background elements in the scene are not redisplayed, the user sees 
the changes in object states without visual disruption. 
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BLADE POSniONING S 




Figure 5. A Scene from the IMTS Bladefold Graphical Simulation 

The total time to update the thirteen-scene Bladefold simulation, in response to a 
student action, is now approximately four seconds. This response time was attained 
only after extensive experimentation, analysis, and modification of alternative 
simulation algorithms. 

The student can also observe the value at a test point by selecting the 
graphical object representing the test equipment to be used, and then selecting the 
test point, as displayed on the functional diagram. The test equipments currently 
provided are a multimeter, oscilloscope, and pressure gauge. Course developers 
can add new test equipments by defining them graphically and functionally, using 
the standard IMTS object authoring system, described below. 

The simulation can represent a normally operating system, or one with one 
or more failures present. If there are failures present, they can either be known to 
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the student or they may be of unknown character, to be determined by the student's 
diagnostic actions. Student?, can replace simulated objects with ones known to be 
good. Upon replacing the malfimctioning component, the student will observe 
entirely normal test results (if there was only one failure present). 

Students move through the scenes of a complex simulation by using a 
hierarchical map of the functional subsystems of the device. The map (Figure 6) is 
always on display, in the upper left portion of the screen. To bring a particular 
scene into the main scene„window, the student selects the corresponding terminal 
node in the map. 




Figure 6. The Scenes Hierarchy and Special Objects Panels 

Students or instructors can create an ad hoc scene containing objects of 
particular interest at any time by selecting the objects from their main scenes and 
copying them into the gray panel at the left of the mnin scene window. The objects 
in this scratch area can be manipulated exactly as are the originals, and they respond 
graphically to all student actions made either on the ad hoc scene or upon the main 
scenes. This feature also facilitates the demonstration and examination of 
interactions of objects that belong to different scenes. 



Authoring the Functional Model 

This section will briefly outline the simulation construction process within the 
IMTS. A more thorough description of the IMTS simulation composition system is 
presented in Towne, Munro, Pizzini & Surmon (1987). 

Authors build graphical simulations using a series of four editors. A 
graphical editor is used to draw new types of components, whenever the required . 
component type is hot already present isi a library. After drawing a component, a 
behavior editor is used to specify-how a component operates, and hew it can be 
connected to other components. 

The scene editor is used to create and to ynnect instances of the generic 
component types (an instance of an object is 'created' by simply selecting a generic 
object type from the library and assigning the object a more specific name). 
Finally, a. scene connection editor is used to indicate how the scenes of simulation 
are interconnected. The scene connection editor also creates links between the 
elements of the scene map and the actual scenes that are accessed by clicking on 
those elements. 

The graphical object editor and the object behavior editor are currently being 
merged into one integrate*! object creation editor. Likewise, the scene editor and 
scene connection editor are being merged into a single multi-scene simulation 
creation editor. 

In some important respects the process of creating IMTS simulations is 
similar to that used in STEAMER (Hollan, 1983; Hollan, Hutchins, & Weitzman, 
1984), which also makes use of graphical editors for objects. A crucial difference 
between the two approaches is that in IMTS, system level behaviors are derived 
from object behaviors, whereas in STEAMER the simulation is produced via 
conventional computer programming techniques, and tiie generic objects portray 
values witiiin the sunulated system. 

The Object Graphics Editor. The object graphics editor allows 
construction of objects using graphical primitives such as line segments, rectangles, 
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ovals, and text elements. Figure 7 illustrates the editor in use, expanding a library 
containing functional representations of objects. Each object shown is 
fundamentally unique, although some may appear similar. Additionally, most of 
the objects are multi-state devices, although each is shown in only one graphic state 
in Figure 7. The toggle switch in the upper left-hand comer, for example, is shown 
in the Up position. The switch below it is also a two-state switch, but differs in the 
number of poles available. 




Figure 7. A Library of Functional Object Graphics 

The Object Behavior Editor. The object behavior editor is used to describe 
how a component operates in each state. In this editor, the user enters niles that 
state the conditions under which the object will take on each state and what output 
values it will propagate to the outside world, as a function of its inputs. The state- 
rules for an object may be functions of the previous state of the object, values of its 
inputs, and relations among its inputs (such as input x > input y). 
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Figure 8 shows this editor being used to define the operation of a two-state, 
hydraulically-actuated, locking device. 



BEHAVIOR EDITOR 
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Figure 8. The Behavior Editor in Use 



The behavior editor automatically generates Lisp code for the user-supplied 
behavior rules, compiles the code, and adds the resulting function to the object 
library. The IMTS simulation driver routine executes these compiled routines 
during training to maintain an accurate graphical representation in response to the 
student's actions. 



The Simulation Editor. The graphic scenes representing sections of the 
real device are composed* using the simulation editor. Authors select generic 
component types from the libraries and position them on the screen, as shown in 
Figure 5. When a new component is juxtaposed to another, adjoining ports are 
automatically connected, i.e., outputs from one component are automatically 
recorded as flowing to the input of the other. The simulation scenes can be 
arbitrarily complex. 
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The Scene Composition Editor. After producing the individual scenes, the 
simulation developer creates a map of the scenes, pre-dously shown in Figure 6. 

The Physical Model 

The primary vehicle operated upon by the student to practice diagnostic actions 
is the physical representation of the target system. 

Adjunct Configuration 

In the adjunct configuration the physical representation is provided in the form 
of videodisk images. A touch panel mounted over the videodisk screen allows the 
student to change a switch r>etting by touching the desired new position. Likewise, a 
test point may be read, after selecting a test equipment, by touching a displayed test 
point and observing the resulting display of the test equipment face. The responses 
of the target device are computed by GMTS, employing its condition-evaluation 
technique (a rule-based form), rather than the device model approach. 

Stand-alone Configuration 

In the stand-alone configuration, the IMTS functional model is used to 
determme system behaviors, and both the functional and the physical 
representations are updated to reflect these computed responses. In this 
configuration the physical model may be represented with either videodisk images 
or computer graphic images. The graphic form of physical objects is created using 
the object graphic editor as shown in Figure 9. 

The graphic views of front panels and odier hardware sections are created by 
building scenes in which the physical objects are simply tied, or slaved, to their 
counterparts in die functiorjal scenes. The slaved physical objects therefore react 
correctiy by.simply referring to the underlying functional model. A physical scene 
can therefore be constructed in which the objects appear to be connected to each 
other, but in fact these apparent connections are not involved in determining system 
behavior. 
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Figure 9. Objects in a Physical Representation 

Links Between the Physical and Functional Representations 

An important concern in designing the IMTS was providing linkages between . 
the physical and functional representations, so that students would experience 
frequent and memorable exposures relating the two. The intention is to promote 
the student's ability to find, recognize, and manipulate physical elements in the real 
system, while maintaining a conception of the functional relationships that cannot 
be seen directly in the real system. 

The techniques to do this involve 1) providing both physical and functional 
representations of the system so that students can examine equivalent views either 
sequentially or simultaneously, and 2) providing both physical and functional views 
of single objects. 
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Physical and Functional System Representations. Because physical 
objects are linked to their functional counterparts, for the purpose of supporting the 
physical simulation, the IMTS will be able to automatically alternate between the 
two, at the request of the student Additionally, the videodisk representation can 
follow along automatically as the student operates in the functional form. Of course 
functional organization is not likely to correspond with physical structure, 
therefore the physical scene corresponding to one functional object might be 
different than that of a neighbor object, and vice versa. 

Physical and Functional Views of Individual Objects. To "lengthen 
the student's understanding of physical and functional equivalence, the IMTS can 
display 'pictures' of individual objects within their functional context In Figure 10 
the student was viewing a ftmctional scene and was curious about the appearance of 
the #1 Damper Positioner (near the upper left). Upon requesting a pictorial view of 
the part the student sees the presentation shown. 




Figure 10. Bladefold Scene with a Digitized Picture 
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SECTION III. Problem Selection and Student Modeling 



In, the current IMTS, the student model is used primarily for the automatic 
selection of appropriate problems for individual students. In future versions the 
current state of the student model may play a role in determining other aspects of 
instruction and aiding, such as frequency of intervening. 

Normative Student Modeling 

IMTS uses an expert, or normative, model to represent device understanding 
for diagnostic functions. This hierarchical model of domain knowledge is created 
by the device expert, and used as the default model of each individual student As 
the student performs troubleshooting problems, the node weights of the model are 
adjusted based on the quality of the problem solving work. This approach is loosely 
based on the student modeling mechanism employed in BIP (Wescourt, Beard, & 
Gould, 1977; Wescourt «& Hemphill, 1978; Wescourt, Beard, Gould,.& Barr, 1977; 
Beard, Barr, Gould,. Wescourt, .1978) in which a model of student knowledge and 
skill was based on a component analysis of the content of a curriculum. The 
curriculum content was represented as a set of elementary concepts and skills. Each 
instructional exercise or problem was considered diagnostic for a particular subset 
of these concepts and skills. Student performance on the problems was used to 
modify a student-specific model of knowledge in the domain. 

The model has the form of a tree in which each node represents the knowledge 
about some aspect of the equipment The highest nodes in the tree represent the 
most abstract knowledge about the global functions of the equipment The nodes 
immediately below that represent top-level knowledge about the major subsystems. 
Lower nodes represent more specific skills and knowledge about modules and 
components. The terminal nodes in the knowledge tree represent knowledge about 
specific component modes, including different possible types of component 
failures. 

The model is linked closely to the structure of the device being simulated. 
This has the advantage of making the creation of such models fairly 
straightforward, and offers the potential for making the normative modeling 
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process automatic. A disadvantage is that generic kinds of knowledge, such as 
Ohm's law, are not easily represented in such an equipment-specific knowledge 
model 

Creating the Normative Model 

The normative knowledge tree is built using the IMTS knowledge network 
editor (see Figure 11). The current implementation of the Knowledge Network 
Editor makes very few assumptions about the structure of knowledge in device 
doinains. (Enhancing the editor to capitalize on domain-specific features is a likely 
topic for future research and development efforts.) Providing structure is the task 
of the knowledge network author. One assumption of the Editor is that device 
knd\yledge can be represented in a simple tree structure. Less specific, more global 
uiformation is represented by nodes near the top or root of the tree. Detailed 
information, such as the particular failure modes of particular elements in the 
device, are represented by nodes at the bottom of the tree. 

Maintaining an Individual Student Model. The understanding of 
individual students is represented by a set of weights for the nodes of the tree. 
These weights represent how well the student understands the corresponding 
portions or functional subsystems of the device. 

When a student finishes a problem, a measure of his or her performance for 
that problem is computed to modify the student model. The node that corresponds 
to the actual malfunction is directly assigned the value of the performance measure. 
Each of the ancestor nodes for that node is also modified to reflect the performance 
as well. The imqiediate parent is modified in the direction of the performance by 
an amount weighted by the number of child nodes that it has. Its parent node is 
similarly modified by an amount relative to the extent of the change in that node, 
and so on up the ancestor tree. A change in a single specific malfunction node can 
have a (usually small) effect even on the top level node, which represents the 
student's understanding of the whole system. 
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Figure 11. The Knowledge Network Editor 
Problem Selection 



Problem selection is made on an individual basis, using the proficiency 
records for the student, as encoded in the student model, and the global measures of 
student ability and cognitive styla. Proficiency is measured by normalized time to 
solve the previous problem and on average test power for the exercise. The model 
is updated at the conclusion of each problem, to support the selection of appropriate 
subsequent problems for students. 
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The problem selection process relies on two measures taken from the 
knowledge structure: conceptual distance and conceptual difficulty. Conceptual 
distance is a simple measure of how related two problems are in terms of the 
domain representation. The conceptual distance between two problem nodes is the 
number of node links that must be-traversed in the knowledge element hierarchy to 
find one node from another, weighted by the student's current mastery levels for 
the intervening nodes. Conceptual difficulty is the value of the "Problem 
Difficulty" field created by the instructor. 

To select a new problem, the remaining troubleshooting exercises are evaluated 
for their conceptual distances from the last problem and their difficulty. An ideal 
conceptoal step size and an ideal difficulty for the next problem are then computed 
for the stodent The desired conceptual step size is a. function of the student's 
estimated learning speed (which is based on prior performance and an instructor 
estimate), a student-controlled value that expresses how large a conceptual jump 
the student likes to make, and the student's performance on the last problem. 

• If the student h^s a high learning speed, conceptual distance can be 
larger. 

• If the student prefers larger conceptual steps, the conceptual distance 
can be larger. 

• If the student did well on the last problem, the conceptual distance can 
be larger. (If the student did poorly on the last problem, a related one 
is called for.) 

• The ideal difficulty level for the student is a function of the student's 
learning speed. 

It is rare that the ideal conceptual distance metric and the ideal difficulty 
metric pick the same problems. A weighting scheme combines these factors. 

Dimensions of Troubleshooting Problem Difficulty 

One of the goals of simulation training is to provide practice at an 
appropriate level of difficulty. If students are presented with problems that are too 
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easy, they will simply reapply old skills and learn nothing new. On the other hand, 
if problems are too difficult, students may become discouraged and fail to learn. 
To a large extent, the difficulty of a troubleshooting problem depends on the 
idiosyncratic knowledge of a student One student of a helicopter bladefolding 
system may be very fainiliar with the hydraulic components responsible for 
positioning the No. 1 blade, while anotiier is more cognizant of the subsystems 
related to the rotor brake. These two students would not order a set of problems 
for difficult in the same way. 

The major components of problem difficulty in IMTS include 

• the size of the initial suspicion set 

• the level of representation required to discriminate the fault 

• the knowledge of detailed component behavior required 

• the remoteness of symptoms from the suspected faults 

IMTS offers se-"eral means of presenting a fault isolation exercise so as to 
reduce or increase its difficulty. These means include managing the instructional 
and aiding features described in Section IV. In addition, it is possible to manipulate 
the complexity of the device representation. 

Controlling the Complexity of the Representation. Using the same 
approach employed for constructing physical representations, simulation 
developers may create alternate forms of representations in which the objects are 
simply slaved to the fully detailed functional model. As a result, highly simplified 
diagrams can be produced Lliat still exhibit accurate behaviors. For students who 
are unfamiliar with the helicopter bladefold system, for example, a simplified 
simulation can be constructed showing only one blade and omitting auxiliary parts 
that are not central to tlie operation of the device. The simplified forms may be 
either functional or physical. 

While the problem selection process does not yet consider moving to problems 
in alternative representations, it will be enhanced to do so when the complete 
authoring capabilities have been completed. 
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SECTION IV. IMBEDDED GENERIC EXPERTISE 



Two kinds of generic expertise are imbedded in IMTS, 1) diagnostic expertise 
and 2) instructional expertise. The diagnostic expertise, in the form of the Profile 
fault-isolation process, is called frequently to assess the student's work and to 
provide technical advice and explanations. The instructional strategy is embodied 
in executive routines that continually assess student progress and call on the 
specialized functions to respond to the student's needs. We first describe the 
generic diagnostic expert model. 

Diagnostic Expertise from Device Data 

An important goal of the IMTS was to generate the diagnostic intelligence for 
a particular device from the sanie functional model that supports the graphical 
representation. This leads to high efficiency of course development, and it ensures 
that the diagnostic expert and the student operate upon the same system model. As a 
result, all diagnostic advice provided can be explicitly rationalized to the student 

To identify, justify, and interpret a good next test, Profile requires data 
specifying the significance of each possible symptom for each possible test, in each 
mode of interest (a mode is a combination of switch settings). This is turn requires 
that the device be simulated in each failure condition to determine what symptoms 
are produced in each specified mode. Because this involves considerable compute 
time, the computation of symptoms is done during the development phase, and the 
results are stored in a data file for quick access during training. 

The utility program that produces the symptom data inserts a failure into the 
device model, it runs the IMTS simulation program in all the modes of interest, as 
specified by the course developer, and it records the results at each indicator and 
test point By comparing each result to that obtained with no failure inserted, the 
program can identify all abnormal symptoms resulting from' the failure. This 
process is repeated for each possible failure. 

While the resulting data file is large, only limited portions are accessed for any 
one practice problex.: The complaint-specific data are read in at the beginning of 
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each problem, and remain accessible throughout the problem. When Profile is 
called upon to suggest a test early in a problem, when there are many alternative 
tests and suspected elements, it requires between five to ten seconds to complete its 
analysis of the alternatives. If the student has performed even one or two useful 
tests, the Profile compute time drops off rapidly to just a few seconds. 

Required Human Expertise 

As mentioned above, human intelligence is required to specify the modes to be 
considered in computing fault effects. To^not constrain this variable would lead to 
impossible data file sizes and compute times. The training implication of this 
restriction is that the IMTS can only monitor and advise the student as long as he or 
she works in one of the recognized modes. Preliminary experience indicates that 
this limitation is not particularly distressing, as each problem has a natural and 
relatively limited set of modes appropriate for fault diagnosis. 

Human knowledge is required to provide a second element, a failure report for 
each practice problem that states the general nature of the problem as it would be 
reported by the equipment operator. These statements typically list one or more 
high-level system functions that do not operate normally, and some conditions, such 
as the mode, under which the abnormality was observed. 

The failure report is displayed at the beginning of each problem, and may range 
from highly informative to quite vague. The course developer has the option of 
issuing the same failure under different failure reports, thereby varying the 
difficulty of the problem. 



FokJ Power On Light does not come on when Master Switch 
l8 placed On. The system Is In Accessory Drive with blades 
^ead. In order to carry cut tests for thn complaint: 1. 
&wure that the Safety Valve Switch Is "OPEN." 2. Ensure 
that ttie Master Switch Is On. 3. Ensure that the Pylon Is 
spread and locked. 

Figure 12. An Initial Failure Report 
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Options for Adding Human Knowledge 

There are two options for enhancing each practice problem by adding human 
knowledge, 1) a hint to help the student get started on the problem, and 2) a 
technical sunmiaiy that explains the physical (electronic, hydraulic, etc.) 
mechanisms of each practice failure. Each of these may be extensive, brief, or 
omitted entirely. 

Problem Hint. If provided, the hint is automatically presented if a student 
is foundering early in the problem and has not requested assistance from the IMTS. 
The hint is associated with the failure report, thus one hint may support 
presentation of many problems. 

K107 must be energized to have power to the Spread/Fold 
circuit. 

Figure 13. A Pre-Authored Hint 

Failure summary. If available, the failure summary is presented upon 
completion of a problem to more fully explain why and how the symptoms were 
produced. Although the simulation routine generated the symptoms, by applying 
and propagating each object's behavior rules, hmnan-supplied explanations provide 
the most rich and meaningful account of the technical nature and consequences of 
the simulated failure. A typical failure summary is shown in Figure 14. 



In order for the safety valve motor to operate, relay K1 02 must energize, 
closing contact B1 to B2. Contact B2 receives its 24V0C directly from the 
safety valve switch. The Safety Valve light also receivas its 24VDC from the 
switch. Therefore, with K1 02 82 shorted to B3, the light can go on, but the 
motor will not operate. 

Figure 14. A Failure Summary 
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Generic Instructional Expertise 

Students have partial control of the aiding features described below. These 
instructional options will be presented automatically to students who need them, 
but» in addition, they can be requested by students. 

Several types of help are available, in addition to the simple hints mentioned 
above. The help functions range in purpose from discussing a single symptom to 
direct instructions about what course of action to follow next These levels of 
aiding make it possible to help a student while still preserving some potential for 
student discovery. Those students who cannot make it through a difficult 
troubleshooting problem on their own can still solve, and learn from, a problem 
through the use of the more directed aiding features. (Currently, the student model 
does not take the degree of assistance provided into account when updating the 
student's proficiency; this will be incorporated in the future.) 

The IMTS uses four different styles of aiding and instructing the student, all 
based on the generic troubleshooting expertise of Profile in exploring and applying 
the fault effect data. 

Within-problem Monitoring and Assistance 

Student performance is monitored within problems to determine what help 
or instruction is required to minimize unproductive time and to help ensure success 
on the problem. Two major elements of the student's performance are tracked 
within a problem: time on the problem and average test power per unit of time on 
the problem. The measure of time spent on a problem is a relative one; time on the 
troubleshooting problem is compared with a parameter that compensates for the 
difficulty of that problem. The average test power measure is more interesting. 
Profile determines the relative power of each test performed by a student by 
comparing it to the one Profile would have performed at that point. The average of 
these values provides a good assessment of a student's diagnostic performance on a 
problem. 
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Parameters ranging from zero to one may be entered by an instructor in 
order to specify the degree to which students may deviate from ideal performance 
before receiving assistance. Four different test power farameters can be set The 
first of these determines at what test power threshold the student will be offered 
instructional help for the first time. A second parameter determines at what 
threshold subsequent offers of help will be made. The third parameter sets the test 
power value at which assistance will be given, whether the student wants it or not, 
and the fourth prescribes the test power level for subsequent enforced assistances. 
A value of 0.5 permits significant departures from maximum test power before 
overt aiding or instructional features are brought into play. 

A prime objective of IMTS is to operate in aw unobtrusive manner, allowing the 
student to practice fault isolation in a more realistic context than one in which 
advice continually intrudes on the troubleshooting process. The MTS remains 
largely invisible to the student until the student requests aid or until the monitoring 
process reveals that the student is having difficulty. The indications of difficulty 
include taking too much time relative to the norms for a problem and making too 
many tests of low power. Possible causes of low diagnostic productivity include 
misinterpretation or misapplication of an earlier test result or inability to identify a 
test that has potential in isolating the source of the problem. 

Eliciting (and Refining) a Student's Suspicions. There are occasions 
during training when assessment of student actions requires knowing the student's 
beliefs or intentions. The major means of ascertaining the student's beliefs about 
the malfunction state is to use the IMTS suspicion eliciting system. The student is 
posed a number of questions about what portions of the device he or she suspects. 
The student's responses are corrected until a set of suspicions has been agreed upon 
that is correct based on the information thus far available. At this point the student 
and IMTS h:"e collaborated to identify a set of suspicions that make sense, given the 
test results that have been seen. 

This process relies upon a representation of the subject device as a hierarchy 
of functional subsystems. In the case of the helicopter bladefold system, for 
example,,the bladefolding mechanism was analyzed as consisting of, first, a 
hydraulic and an electrical subsystem. Each of these was treated as having a 
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number of major Uescendent subsystems, and so on. At the lowest level in this 
analysis are particular failures; just above this level are replaceable components. 
This analysis of the higher level structure of the device is similar in many respects 
to the normative student model created with the knowledge network editor 
described in Section III. In a future version of IMTS, the same data structure will 
fill both roles — the normative knowledge model and the hierarchical structure of 
the device used to discuss suspicions. 

The first time that a student's suspicions are elicited, the IMTS asks whether 
the student suspects any of the highest level subsystems. In the case of the Bladefold 
system, the student would be asked whetlier anything should be suspected in the 
electrical system and whether anything should be suspected in the hydraulic system. 
If the symptoms obtained by the student justify reducing the suspected set to only 
one of the subsystems, then the process of eliciting suspicions continues by 
inquiring about each of the subsystems of that system. 

Figures 15 and 16 present the suspicion eliciting system of IMTS in action. The 
panel in Figure 15 lists the subsystems that should be considered at any particular 
level of system orgaiuzation. The routine steps through this list, highlighting the 
subsystem currently in question. 
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Figure 15. A Portion of the IMTS Suspicion Eliciting Mechanism 
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Figure 16 shows the student being asked about his suspicion of the Bladefold 
Power Circuit, and being shown the components in this subsystem, for reference. 



Do you 9Utp«ct torn part of the BLADEFOLD POWER 
CIRCUIT 



YES 



NO 



BUttofold Mttttr Switch (S24) 
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Fold Powor On Light Bulb (0S7) 

Kiel A2/A3 

KieO A1/A2 

K180 Coll 

K1S7 A1/A2 

C«bl0t Kir/7 Al to K194 A2 
KIN 01/02 
Kill A2/A3 

Ctb1o» 6Ud«fo1d Mtttor Sultch to K180 01 
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Figure 16. The Details Panel in Suspicion Eliciting 

The IMTS keeps track of the significance of tests as they are performed by 
the student, remembering which suspected elements could have been eliminated by 
each. It can therefore tell a student why a particular element should no longer be 
suspected* If a student suspects an element when a previously-conducted test should 
have eliminated it from suspicion, then IMTS reminds the student of that test and 
the value it revealed (see Figure 17). Here the student has just indicated that he 
suspects the Bladefold Master Switch. IMTS points out that a previously seen test 
result should have eliminated this circuit from suspicion. 
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Figure 17. Refining Student Suspicions 

Explaining the Meaning of the Most Recent Test The elicitation and 
remediation of beliefs about possible failures considers all previous tests performed 
by the student on that problem. Sometimes the student may need assistance in 
interpreting a particular symptom. He or she may request that IMTS interpret the 
symptom when it is displayed. 

In response to the request, the IMTS first recapitulates the observation and 
states whether the observed value is normal or abnormal. Based on that judgement, 
it lists the subsystems o^ objects that should still be suspected and those that should 
no longer be suspected. 

Thke voltage at K101-A2 was 28V-DC, whtch Is 

MORMAL, so we now know that the following components 

are working normally: 

Circuit Breaker 80 

Accessory Drive Switch (S51) 

Bladefoki Master Switch (924) 

K111 A2/A3 

K107A1/A2 

K115A2/A3 

Safety Valve Switch (S25) 
K107Coil 

Pylon Lockpin Lknlt Switch (S76) 
Pykxi Limit Switch (S77) 
and associated cables 

We still suspect the followinQ: 
BLADEFOLD POWER CIRCUIT 
ACCESSORY DRIVE CONTROL CIRCUIT 

Figure 18. Explaining Diagnostic Test Results 

Suggesting Troubrieshooting Actions. Sometimes a student requires 
very direct assistance in proceeding on a problem. In general, this could be termed 
a 'planning' skill, although in diagnosis th(^. scope of future considerations is 
normally limited to just identifying the next best action. 
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It could be argued that in such a case the student's instructor should be notified 
so that the student can receive individual attention and instruction. In those cases in 
which instructor time is largely committed, this level of individualized instruction 
may be difficult to guarantee. Even if the instructor were always available, 
howeyer^ it is likely that a mandatory interruption in the student's practice problem 
for instructor remediation could quickly come to be viewed as a signal of failure. 

An alternative approach is to provide mechanisms that assure that the student 
can never reach a complete impasse. Recent research (Fox, 1987) suggests that 
human tutors try to prevent failure. The IMTS approach to doing this on the 
troubleshooting task is to provide the student with suggested troubleshooting 
actions that are guaranteed to be useful and rational (and are actually near-optimal). 
Figure 19 shows the form of such advice. 



Measure the voltage at Ki0i-A2 
28V-OC would be non'iial. 

If nonnat, the failure Is one of: 
KiOi >^/A3 
K106A1/A2 
KiOeColl 

FoW Power On Light Bub (DS7) 

Circuit Breaker 50 

No. 2 Engine Firewall Valve Switch 

No. 2 Fire Emergency Shut Off (S8} 

Linear Actuator 

and associated cables 

If abnormal, the failure Is one of: 
Circuit Breaker 80 
Access ory Drive Switch (S5i) 
Safety Valve Switch (S25) 
Bladefold Master Switch (S24) 
PytonlJmit Switch (S77) 
K111 A2/A3 
K107A1/A2 

Pylon Loctoin Limit Switch (S76) 

K115A2/a3i 

K107Coil 

and associated cables 



Figure 19. Generated Troubleshooting Suggestions 



By exploring the fault-effect data, following each test performed by the 
student, Profile identifies the next test that will best discriminate among the current 
suspicions. This process is done whether or not the student requests assistance. If 
the student proceeds without getting help, then Profile simply compares the 
student's test to its own selection, to yield a test power measure. If the student 
requests assistance in proceeding, then Profile presents and explains its selection. 
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Between-problem Instruction 



Because a fault isolation exercise involves an unknown to be discovered by die 
student, die IMTS attempts to defer some remediations and explanations — those 
diat would destroy die value of the problem until after the problem has been 
conipleted. At that time, a number of choices are offered for further exploring the 
now-known failure, as shown in Figure 20. 



What do you w^jnl to do nexlV 



See Expert Solution 



Replay Student Solution 



IMTS SimulatiMi 



Go On To Nexi GMTS Problem 



Slop Session 



Figure 20. The Student's Choices Between Problems 

These choices include two instructional options that, like those already 
discussed, make use of the Profile analysis of the troubleshooting context: 
presentation of an expert solution and a critiqued replay of the student's solution. 

Expert Troubleshooting of the Same Problem. The IMTS describes 
each action that Profile dictates for troubleshooting the reported fault and it 
interprets die results that would be seen for each. The interpretation lists the 
elements eliminated from suspicion by die test and diose for which suspicion should 



increase as a result of the test Figure 21 shows the start of such an expert solution 
of a problem. 



Fold Power On Light does not come on when Master Switch 
\s placed On. The system is in Accessory Drive with blades 
spread. In order to carry out tests for this complaint: 1. 
Enaure that the Safety Valve Switch to "OPEN.** 2. Ensure 
that the Master Swlt^^ iki On. 3. Ensure that the Pylon to 
spread and locked. 

I wm measure the vottaoe at K101-A2 

The vottage ait kl01-A2 was which to 

NORMAL, so wenow know that the foUowIng components 

are worklnQ normally^ 

Circuit Breaker 80 

Accessory Drive Switch (S51) 

Btodefokf Master Switch (S24) 

K111 A2/A3 

K107A1/A2 

K115A2/A3: 

Safety Valve Switch (S25) 
K107Coll 

Pylon Lockpki Umh Swhch (S76) 
Pylon Limit Switch (S77) 
and asspctoted cables 

I still suspect the following: 
BLAD^OLD w-^WER CIRCUIT 
ACCESSORY DRIVE CONTROL CIRCUIT 



Figure 21 . Presentation of a Generated Expert Troubleshooting Sequence 



Debriefing the Student with a Problem Replay. Another option 
offered to students at the end of a troubleshooting problem is to review their own 
sequence of actions, with generated commentary. This presentation describes what 
the student should have learned from each test that was performed, and identifies 
tests that had no value in the context of the troubleshooting sequence followed. See 
Figure 22. 



Fold Power On Light does not come onrwhen Master Switch 
is placed On. The system is In Accessory Drive with blades 
oxead. In order to can7 out tests for the complaint: 
Bmire tt^t the Safety Valve Switch is **OPEN/* 2. Filnsure 
that the Master Swltcn is On. 3. Ensure that the Pykxi is 
spread and locked. 

tMext, you set the Eiectrlc/Hydraullc Power 
switm to On 

tMext, you cet the Safety Valve Switch (S25) 
switch to Open 

tvlext, you set the Master Switch (S24) 
switch :d On 

Observing ttie Fold Power On Light Bulb did not provide 
any Information that coutdnt t>eTlgured out from the 
original symptoms. 

Figure 22. Problem Replay vnth Generated Commentary 
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SECTION V. CONCLUSIONS 



Findings and Recommendations 

In the course of this research and development project, we have explored a 
number of alternative approaches to simulation, student monitoring, problem 
selection, and student aiding. In addition to the techniques presented here, other 
less successful approaches were developed, evaluated, and discarded. To share both 
the successes and failures, we present the following conclusions. 

Device models for simulation-based diagnostic training should 
support quantitative modeling. To some extent, the object behavior rules in 
the Mrs appear qualitative. For example, a typical rule states that something 
happens when a value at one port is larger than the value at another port. This type 
of ejipressiori is effective because that is the way the object actually behaves. In 
other cases objects resppnd.to the values at ports. For example, certain pressure 
valves change state when the pressure exceeds some characteristic value. 
Furthermore, to correctly determine how resistive parts will behave in an electrical 
circuit, it is necessary to kefep track of very precise values within the circuit As a 
result, the IMTS simulation program is essentially quantitative. 

It. is tempting to develop a simulation composition system that does not require 
that accurate quantitative values be passed from one object to another. At first 
blush, it appears that both the authoring of object behaviors and the simulation 
driver software can be made simpler by using a qualitative or 'fuzzy' quantitative 
approach. Unfortunately, when objects pass imprecise values, two serious 
problems arise in the simulation. First, it becomes awkward or impossible to 
provide simulated test equipment. Special-purpose simulated test equipment must 
be constructed that translates inaccurate or non-quantitative values and converts 
them into the nominal values expected in the device. This would be necessary if the 
student is to be able to practice interpreting quantitative readings back to qualitative 
judgements such as "normal" or "high". 

Second, in complex devices, it becomes diffiCTilt or impossible to avoid 
incorrect device responses, owing to inaccuracies in internal effects. In summary, 
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simulations of complex systems tend not to work when the underlying model is 
approximate. 

This is in no way intended to minimize the fascinating work being done with 
qualitative models. We simply find that complex models may not respond correctly 
when they operate upon approximate values. Further this finding does not suggest 
that human diagnosticians operate quantitatively. In fact, the quantitative 
manipulations that the IMTS simulation program performs, to maintain the 
graphical simulation, are not apparent to the student 

Visual representations must not be tightly linked to the device 
model. Instructors and: simulation developers need to be able to make simplified 
presentations that do not involve every element in the real device. Yet, if the 
graphical objects can obtain theu: behaviors only from then: own underlying 
functional behavior rules, then every component would have to be included. This 
awkward restriction led to the development of the feature that allows physical 
simulations and simplified simulations to obtain their behaviors firom objects in the 
functional model. 

Advice does not have to be optimal, but it must be rational. One 

of the most important aspects of successful training using computer-generated 
materials is maintaining the trust and confidence of the learner. For complex 
systems, slight non-optimalities in advice are very unlikely to be noticed in the 
course of a single student's instruction. In fact, moderate non-optimalities are 
scarcely a matter of concern, since even excellent human tutors are significantiy 
non-optimal in the troubleshooting strategies they demonstrate. On tlie other hand, 
irrational advice is devastating to student confidence. It is much better for an 
artificial instructor to remain silent than to risk offering truly questionable advice. 

Assessment of student performance must be accurate and based 
upon very recent performance. It is frustrating for a student who has been 
struggling, but who has just seen the light and begun to make progress in a problem, 
to suddenly be interrupted with unwanted admonitions and instruction. It is 
probably better to err on the side of too few interruptions than to interrupt 
excessively. Further, it has been found crucial to only consider very recent 
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performance, in deciding when to intervene, as lengthy moving averages can 
trigger interruptions even when the student has just corrected course, and is on the 
way to a solution. 

Accurate tracking of the student conflicts with the goal of a 
transparent and efHcient practice environment Many of the actions that 
students take could have several different rational motivations. The number of 
irrational motivations for a test or replacement is unbounded. In order to really 
know what the student intends, it is probably iiecessary to ask. Unfortunately, 
constantly harassing the student with demands that every action be justified in detail 
radically changes the nature of the troubleshooting task (and makes it very 
unpleasant). A balance must be sought to ensure effective training, and the artificial 
instructor must always be aware that its model of student intent is probably 
imperfect. 

The need to ask.the student about beliefs or intentions was part of the 
motivation for the development of the suspicion eliciting system used in MTS. 
Further work is underway to reduce the intrusiveness of this process, so that it can 
be used more often. This will make it possible to track student intent more closely 
without damaging the natural troubleshooting process. 

Parameters currently used to manage instruction are arbitrary. 

In the present system, interventions are based upon accurate computations of 
student performance, compared to quite arbitrary threshold values (such as 
inactivity exceeding three minutes, or two irrational tests in a row). Ideally, a 
science of instruction would serve ^'S the basis for determining the appropriate 
parameters for making decisions about instructional intervention. 

Precomputing of fault effects is necessary. For a very complex 
device, a single fault can have many effects. To discriminate among possible faults, 
all the effects of each fault must be computed. Although we have made very 
significant improvements in simulation speed by aggressively pursuing that goal, 
computed simulations cannot be made instantaneous. Where a large number of 
faults must be considered, each with a significant number of effects, precomputing 
these effects is essential to providing advice to students in a timely fashion. 
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The Next Steps for Enhancing Training in IMTS 



IMTS represents a powerful environment for producing and delivering 
interactive simulation training. It also constitutes a promising foundation on which 
to build an even niore caipable technical training system. Here we briefly touch on 
the features to be implemented in the near future. 

Simulation of Partially Specifiable Systems. Some equipment 
systems, such as Bladefpld, lend themselves to simulation based on detailed 
descriptions at.th<* coinpohent level This level of description is appropriate when 
the number of low-level components (such as relay contact sets, switches, lights, 
and pressure snubbers) is hot so large that it is infeasible to draw them, describe 
their behaviorSj,and specify their connections. This is the way that the IMTS 
Bladefbld simulation has been implemented. 

Other equip oient systems are much too large and complex to be described in a 
similar manner, as too much time would be required to produce detailed behavior 
descriptions of every component. An alternative approach, capable of providing 
training for devices of arbitrary complexity, is required. For such complex 
systems, IMTS will make use of system level descriptions instead of component 
level descriptions. 

In both approaches to IMTS simulation training, the aiding and instructional 
features are based on the Profile system's analysis of fault effect data. In the case of 
simulations based on detailed component descriptions, this fault effect information 
is generated automatically from the 'deep' device model. In the case of simulations 
based on system-level descriptions, a subject matter expert generates the fault effect 
data. For the latter type of IMTS simulations, the fault effect data are used to drive 
the simulation of the target equipment For the former type, the simulation is 
generated by a device model based on detailed descriptions of the behavior of the 
device's components (see Figure 23). 
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Subjactj-X 
Manor > 
Expert yy 



Device Deecription 








Block 
Structure 














Device 
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Gentric 
Ot)itc1i 








Scene 

Structure 
















IMTS Based on Detailed Component Descriptions 




IMTS Based on Syf tern Level Desalptions 



Figure 23. Two IMTS Approaches to Device Representation & Training 

Authored Procedure I'raining. Instructors will be able to create guided 
simulations for teaching particular procedures. The authoring process will consist 
of putting a graphical simulation into record mode, and then carrying out the set of 
actions that they want to require their students to perform. Authors will also have 
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the option of entering small blocks of text that can appear at specified points in the 
sequence of actions they record. 

During the procedure training, students see the text blocks, which describe 
what is required of them. When a student performs a required action, the 
simulation updates and the next text block is presented. If the student performs 
some action other than the scripted (recorded) one, then the required action will be 
graphically highlighted. 

The same methods will ht applicable to other training requirements in 
addition to procedure training. For example, ad hoc instructional elements will be 
easily authored using the simulation record mode. Instructors who wish to teach a 
particular approach to troubleshooting a certain fault will be abb to record the 
sequence of actions they use to troubleshoot the fault, adding explanatory text as 
they go. In the simulation playback mode, students will be guided to perform the 
same troubleshooting steps. 
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